Rishard E.
Èñòî÷íèê: Rishard E. ''Managing and Leading Software Projects", p.226
1. Analogy
Analogy is a widely used technique for estimating project attributes in software engineering and other engineering disciplines. The goal of analogy – based estimation is to find one or more analogous projects for which the attributes of interest are known. The closer the analogy, the more confident you will be in your estimate. A rule of thumb, for example, can be used with greater confidence if it is based on projects that are analogous to the one you are estimating. Analogy – based estimates can be simple (e.g., a similar project required 5 people for 6 months) or sophisticated. In the latter case, your organization might have a relational database of past projects. Each row in the data schema would contain data for a completed project. Each column would record an attribute of past projects, such as:
To make an estimate, you would specify the known characteristics of the project you are estimating. You would then write a query that retrieves a list of projects that match your project within a specifi ed range, for example, all projects that developed products of high complexity and that are within 10% of your estimated size built by developers of average skill levels using C++ and an Incremental – build model.
The primary strength of analogy – based estimation is that: good analogies provided a good basis of estimation for your project.
The primary weakness is that: false analogies produce inaccurate estimates.
The estimate is no better or worse than the analogies on which it is based.
2. Expert Judgment
Expert judgment involves asking one or more experts for their estimates of project attributes such as effort, time, required skill levels, and risk factors. The adjustment factors they apply may include subjective factors such as knowing the people who will do the work and manage the work, the politics of customer relations, and frictions that may exist among internal elements of the organization. Product attributes include whatever information is available for the experts to examine. Experts might tell you that the requirements are too vague and incomplete for them to render an opinion (which is useful to know). At the other extreme, different kinds of experts may be able to provide estimates for different elements of the architecture decomposition view (ADV) of the envisioned system or product (e.g., the user interface, the database, the communication package, the algorithms).
The primary strengths of expert judgment are that: different kinds of experts can provide estimates for different kinds of product; components; experts can include subjective and political factors that are not typically; recorded in databases of past projects.
The primary weaknesses are that: experts may be overoptimistic in estimating the time and resources needed for; them to do the work rather than the time and resources needed by less – expert developers; their recall of past experiences may be incorrect or incomplete.
3. WBS / CPM / PERT
The WBS/CPM/PERT approach to estimation is based on the architecture decomposition view embedded in the WBS and the WBS work packages. As discussed work packages can be used to provide bottom – up estimates of project attributes by rolling up lower level estimates for activities and tasks. The work package estimates can be based on other pragmatic techniques (rule of thumb, analogy, Delphi, expert judgment) or on theory – based or regression – based estimation models. I participated in one such meeting in which a participant commented "Who is the idiot that submitted that estimate?" The comment was not conducive to a collegial outcome.
Èñòî÷íèê: Rishard E. ''Managing and Leading Software Projects", p.226